1. Field of the Invention
Embodiments of the present invention generally relate to sequenced applications, and, in particular, to a system and method for sequenced applications to indirectly influence the SIP routing of calls.
2. Description of Related Art
Session Initiation Protocol (SIP) is an open signaling protocol for establishing many kinds of real-time communication sessions. Examples of the types of communication sessions that may be established using SIP include voice, video, and/or instant messaging. These communication sessions may be carried out on any type of communication device such as a personal computer, laptop computer, Personal Digital Assistant, telephone, mobile phone, cellular phone, or the like. One key feature of SIP is its ability to use an end-user's Address of Record (AOR) as a single unifying public address for all communications. Thus, in a world of SIP-enhanced communications, a user's AOR becomes their single address that links the user to all of the communication devices associated with the user. Using this AOR, a caller can reach any one of the user's communication devices, also referred to as User Agents (UAs) without having to know each of the unique device addresses or phone numbers.
Many SIP communications are enhanced by virtue of the fact that an application is inserted or included into the communication session during the establishment of that session. The incorporation of applications into a communication session is typically referred to as application sequencing because the applications are sequentially invoked during the establishment of the communication session. In some instances the applications are owned and operated by an enterprise that is administering the SIP network. In some instances, the applications may be provided by third-party vendors. In either event, the traditional way in which applications were included in the communication session was during the communication session establishment stage so that these applications can insert themselves into the signaling and media path of the communication session.
Exemplary types of applications that may be utilized for a communication session include, without limitation, call recording applications, communication log services, conferencing applications, security applications, encryption applications, collaboration applications, whiteboard applications, mobility applications, presence applications, media applications, messaging applications, bridging applications, and any other type of application that can supplement or enhance communications.
Session managers such as Avaya Aura™ for enterprise telephony networks allow sequencing of network applications at session origination and termination phases, in order to affect the way the session is routed in the network, and to allow features to be independently added to the system for handling a call.
A drawback of the known art is that there exists limited communication among sequenced applications. Although the SIP History-info message can help downstream applications discover upstream routing decisions, this message does not allow upstream apps to learn about downstream routing decisions. Furthermore, reliance upon the SIP History-info message does not prevent downstream applications from being bypassed by an upstream application. Limited communication also makes difficult coordinating communication among sequenced applications.
If an application independently processes SIP requests, downstream applications are easily bypassed or prevented from seeing the original request or how upstream applications processed the request. It also is difficult to arbitrate call control between upstream and downstream applications. For example, an upstream application may not want a call to be forwarded, but a downstream application may forward the call without guidance from the upstream application. Or, an upstream application may forward a call by retargeting the request; thus, bypassing the downstream altogether from ever seeing the request. Because of these issues, knowing the order of the application in the target deployment configuration becomes a critical factor for the application developer. Moreover, certain positions in the sequence, like first and last application in originating and terminating sequence, have become the sought after positions for majority of the applications.
Another drawback of the known art is that sequenced applications have strong coupling to one another and to their order of execution. Therefore, the sequence of applications is difficult to design or modify, and may be more prone to error or unexpected result when modified.
RFC 3841 describes a set of extensions to SIP which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences with respect to proxy behavior. However, this solution is limited to the call originator, and does not address sequenced applications and media control, nor does it deal conflicts between multiple applications since there is only one entity (i.e., the UAC) adding preferences.
Use of a new or proprietary data field in the message or control data streams associated with the sequenced application may be known in the background art. For example, a History-info field may be used to inform downstream applications about upstream routing decisions. But a shortcoming of this process is that if the request is retargeted, information in the history-info field cannot prevent the downstream applications from being bypassed.
The known art of designing sequenced applications or sequencing the applications by use of B2BUA/Proxy, or by limiting usage by way of a proprietary history-info field do not address the problems identified above. For example, the known art do not reliably allow more than one sequenced application to influence routing. Another drawback of the known art is that the sequence in which applications are ordered (i.e., the execution order) affects the overall behavior of the applications together. Furthermore, there is no arbitration mechanism to resolve conflict among the sequenced applications.
These problems are limiting the proliferation and wide-spread adoption of applications based on Application Sequencing approach.
Therefore, a need exists to provide better awareness of the context of applications within a sequence vector in order to provide a more compatible and harmonious execution of sequenced applications.